Problem

EntityTransaction.mergeFind currently locates an existing row on the receiver with findTransactions({ partial: { reference, userId } }). But reference is a locally-assigned random value — each storage that first ingests a txid invents its own reference (via createAction or internalizeAction). It is not a cross-storage identifier.

If two storages independently ingest the same bitcoin transaction before sync has had a chance to propagate between them, they each assign a different reference to the same txid. Every subsequent sync between those storages then fails to recognize the rows as the same transaction: mergeFind by reference misses, mergeNew fires, and a duplicate row is inserted on the receiver.

Reproduction observed in yours-wallet

1. User wipes local IndexedDB.
2. syncAddresses runs against the now-empty local storage and calls internalizeAction for every BRC-29 address output found on the indexer, including inbound ordinals that the user had received long before. Each call generates a fresh local reference.
3. User re-attaches a remote storage that already holds those same txids under its own references (from a prior session).
4. setActive runs syncToWriter, processSyncChunk invokes mergeFind, the references don't match, every txid duplicates on the remote.

The user's ordinals then appear twice in the wallet UI.

Fix

Match by (userId, txid) when the incoming row has a txid. Fall through to (userId, reference) only for pre-broadcast rows that have not yet learned their txid — this preserves correctness for the createAction → sync-while-unsigned → signAction → sync-again flow, where the receiver's pre-broadcast row has the reference but no txid yet and needs to be matched on reference so mergeExisting can stamp the txid on it.

mergeExisting already treats reference as never-updated, so the fix leaves each storage's local reference intact; they diverge across storages, as they always did, but sync reconciles by txid and no duplicates are produced.

Scope

One function, one file. No schema changes. No other entity's mergeFind is affected.

Verification

Built against 2.1.22. Reproduced the duplication pre-fix in a live wallet, applied the fix, re-ran the same attach-remote flow end-to-end, and confirmed one row per txid on both sides with each retaining its own reference.